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ATM Signaling Support for IP over ATM 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This memo describes the ATM call control signaling exchanges needed 
to support Classical IP over ATM implementations as described in RFC 
1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services 
as specified in the ATM Forum User-Network Interface (UNI) 
Specification Version 3.1 [ATMF94]. IP over ATM implementations 
utilize the services of local ATM signaling entities to establish and 
release ATM connections. This memo should be used to define the 
support required by IP over ATM implementations from their local ATM 
signaling entities. 


This document is an implementors guide intended to foster 
interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It 
applies to IP hosts and routers which are also ATM endsystems and 
assumes ATM networks that completely implement the ATM Forum UNI 
Specification Version 3.1. Unless explicitly stated, no distinction 
is made between the Private and Public UNI. 
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UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has 
been produced by the ATM Forum, largely for reasons of alignment with 
Recommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are 
several changes that make the two versions incompatible. A 
description of how to support IP over ATM using UNI 3.0 is found in 


Appendix B. 
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Conventions 


The following language conventions are used in the items of 
specification in this document: 


2 


fe) MUST, SHALL, or MANDATORY -- the item is an absolute requirement 
of the specification. 


fe) SHOULD or RECOMMEND -- this item SHOULD generally be followed for 
all but exceptional circumstances. 


fe) MAY or OPTIONAL -- the item is truly optional and MAY be followed 
or ignored according to the needs of the implementor. 


Overview 


In a Switched Virtual Connection (SVC) environment, ATM virtual 
channel connections (VCCs) are dynamically established and released 
as needed. This is accomplished using the ATM call/connection control 
signaling protocol, which operates between ATM endsystems and the ATM 
network. The signaling entities use the signaling protocol to 
establish and release calls (association between ATM endpoints) and 
connections (VCCs). Signaling procedures include the use of 
addressing to locate ATM endpoints and allocation of resource in the 
network for the connection. It also provides indication and 
negotiation between ATM endpoints for selection of end-to-end 
protocols and their parameters. This memo describes how the 
signaling protocol is used in support of IP over ATM, and, in 
particular, the information exchanged in the signaling protocol to 
effect this support. 


IP address to ATM address resolution and routing issues are not in 
the scope of this memo, and are treated as part of IP in figure 1. 


4+-------------- + +------ + 4+---------- + 
| | | |<--->| IP / ARP | 
| |<--->| This | | RFC 1577 | 
| ATM | | Memo | +---------—- + 
| signaling | | |<--->| RFC 1483 | 
+------ + 4+---------- + 
—------------ > | AALS5 | 
| | t--------—- + 
| | 00 ------------- > | AT™ | 
+-------------- + 4+---------- + 
Figure 1. 


Relationship of this memo to IP, RFC 1483, 
ATM signaling, ATM and AAL5 
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Use of Protocol Procedures 


The following requirements are motivated to provide implementation 
guidelines on how multiple ATM connections between peer systems 
SHOULD be managed, to prevent connection thrashing and related 
problems. 


1. VC Establishment 


The owner of an existing VCC is defined to be the entity within the 
ATM endsystem that establishes the connection. An ATM endsystem MAY 
establish an ATM call when it has a datagram to send and either there 
is no existing VCC that it can use for this purpose, it chooses not 
to use an existing VCC, (e.g., for reasons of route optimization or 
quality of service), or the VCC owner does not allow sharing. 


To reduce the latency of the address resolution procedure at the 
called station, the following procedure MAY be used: 


If a VCC is established using the LLC/SNAP encapsulation, the calling 
endstation of the VCC MAY send an InARP_REQUEST to the called 
endstation after the connection is established (i.e. received a 
CONNECT message) and before the calling endstation sends the first 
data packet. In addition, the calling endstation MAY send its data 
packets without waiting for the InARP_REPLY. An endstation MAY 
respond, generate, and manage its ATMARP table according to the 
procedures specified in RFC1293 [BRAD92], Section 7, "Protocol 
Operation", during the life time of the VCC. 


To avoid establishing multiple VCCs to the same endstation, a called 
endstation MAY associate the calling party number in the SETUP 
message with the established VCC. This VCC MAY be used to transmit 
data packets destined to a endstation whose ATMARP resolution results 
in an ATM address that is the same as the associated calling party 
number. Sharing of VCCs is subject to the policies configured at the 
endstation as described in section 4.3 of this recommendation. 


-2. Multiprotocol Support on VCs 


When two ATM endsystems run multiple protocols, an ATM connection MAY 
be shared among two or more datagram protocol entities, as long as 
the VCC owner allows sharing and if the encapsulation allows proper 
multiplexing and demultiplexing (i.e. the LLC/SNAP encapsulation). 
This indication of sharing a VCC MAY be by configuration or via an 
API. Similarly, the Internet layer supports multiplexing of multiple 
end-to-end transport sessions. To properly detect idle connections 
while sharing a VCC among more than one higher layer protocol 
entities, the ATM endsystem MUST monitor the traffic at the lowest 
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multiplexing layer. 
3.3. Support for Multiple VCs 


An ATMARP server or client MAY establish an ATM call when it has a 
datagram to send and either there is no existing VCC that it can use 
for this purpose, it chooses not to use an existing VCC, or the owner 
of the VCC does not allow sharing. Note that there might be VCCs to 
the destination which are used for IP, but an ARP server might prefer 
to use a separate VCC for ARP only. The ATMARP server or client MAY 
maintain or release the call as specified in RFC 1577. However, if 
the VCC is shared among several protocol entities, the ATMARP client 
or server SHALL NOT disconnect the call as suggested in RFC 1577. 


Systems MUST be able to support multiple connections between peer 
systems (without regard to which peer system initiated each 
connection). They MAY be configured to only allow one such 
connection at a time. 


If a receiver accepts more than one call from a single source, that 
receiver MUST then accept incoming PDUs on the additional 
connection(s), and MAY transmit on the additional connections. 
Receivers SHOULD NOT accept the incoming call, only to close the 
connection or ignore PDUs from the connection. 


Because opening multiple connections is specifically allowed, 
algorithms to prevent connection call collision, such as the one 
found in section 8.4.3.5 of ISO/IEC 8473 [1IS08473], MUST NOT be 
implemented. 


While allowing multiple connections is specifically desired and 
allowed, implementations MAY choose (by configuration) to permit only 
a single connection to some destinations. Only in such a case, if a 
colliding incoming call is received while a call request is pending, 
the incoming call MUST be rejected. Note that this MAY result ina 
failure to establish a connection. In such a case, each system MUST 
wait at least a configurable collision retry time in the range 1 to 
10 seconds before retrying. Systems MUST add a random increment, 
with exponential backoff. 
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3.4. VC Teardown 


Either endsystem MAY close a connection. If the connection is closed 
or reset while a datagram is being transmitted, the datagram is lost. 
Systems SHOULD be able to configure a minimum holding time for 
connections to remain open as long as the endpoints are up. (Note 
that holding time, the time the connection has been open, differs 
from idle time.) A suggested default value for the minimum holding 
time is 60 seconds. 


Because some public networks MAY charge for connection holding time, 
and connections MAY be a scarce resource in some networks or 
endsystems, each system implementing a Public ATM UNI interface MUST 
support the use of a configurable inactivity timer to clear 
connections that are idle for some period of time. The timer’s range 
SHOULD include a range from a small number of minutes to "infinite". 
A default value of 20 minutes is RECOMMENDED. Systems which only 
implement a Private ATM UNI interface SHOULD support the inactivity 
timer. If implemented, the inactivity timer MUST monitor traffic in 
both directions of the connection. 


4. Brief Overview of UNI Call Setup Signaling Procedures and Messages 


This section provides a summary of point-to-point signaling 
procedures. Readers are referred to [ATMF93]. 


UNI signaling messages used for point-to-point call/connection 
control are the following: 


Call Setup Call Release 
SETUP RELEASE 
CALL PROCEEDING RELEASE COMPLETE 
CONNECT 


CONNECT ACKNOWLEDGE 


An ATM endpoint initiates a call request by sending a SETUP message 
to the network. The network processes the call request to determine 
if the call can be progressed. If so, the network indicates the value 
of the newly allocated VPCI/VCI in its first response to the the 
SETUP message, which is either a CALL PROCEEDING or CONNECT message. 
If a call cannot be accepted, by the network or destination ATM end- 
point, a RELEASE COMPLETE is sent. At the destination ATM endpoint, 
the network offers the call using the SETUP message. If the 
destination endpoint is able to accept the call, it responds with a 
CONNECT message (which MAY be preceded by a CALL PROCEEDING) ; 
otherwise, it sends a RELEASE COMPLETE message. See Appendix A, 
Section 2 for guidance on the use of the CALL PROCEEDING message. 
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Call release can be initiated by either endpoint or (rarely) by the 
network. When an endpoint wishes to release a call, it sends a 
RELEASE message to the network. The network responds with a RELEASE 
COMPLETE message, frees up resources associated with the call, and 
initiates clearing toward the other endpoint. The network initiates 
clearing by sending a RELEASE message to the ATM endpoint, which 
reponds by sending a RELEASE COMPLETE message. Upon receipt of the 
RELEASE COMPLETE message, the network frees any resources associated 
with the call. 


5. Overview of Call Establishment Message Content 


Signaling messages are structured to contain mandatory and optional 
variable length information elements (IEs). IEs are further 
subdivided into octet groups, which in turn are divided into fields. 
IEs contain information related to the call, which is relevant to the 
network, the peer endpoint or both. Selection of optional IEs and 
the content of mandatory and optional IEs in a call establishment 
message determines the parties to and nature of the communication 
over the ATM connection. For example, the call establishment message 
for a call which will be used for constant bitrate video over AAL 1 
will have different contents than a call which will be used for IP 
over AAL 5. 


A SETUP message which establishes an ATM connection to be used for IP 
and multiprotocol interconnection calls MUST contain the following 
IEs: 


AAL Parameters 

ATM Traffic Descriptor 
Broadband Bearer Capability 
Broadband Low Layer Information 
QoS Parameter 

Called Party Number 

Calling Party Number 


and MAY, under certain circumstance contain the following IEs: 


Calling Party Subaddress 
Called Party Subaddress 
Transit Network Selection 


In UNI 3.1, the AAL Parameters and the Broadband Low Layer 
Information IEs are optional in a SETUP message. However, in support 
of IP over ATM these two IEs MUST be included. Appendix A shows an 
example SETUP message coded in the manner indicated in this memo. 
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6. Information Elements with Endpoint to Endpoint Significance 


This section describes the coding of, and procedures surrounding, 
information elements in a SETUP message with significance only to the 
endpoints of an ATM call supporting IP. 


6.1. ATM Adaptation Layer Parameters 


The AAL Parameters IE (see section 5.4.5.5 and Annex F of [ATMF93]) 
carries information about the ATM Adaptation Layer (AAL) to be used 
on the connection. RFC 1483 specifies encapsulation of IP over AAL 5. 
Thus, AAL 5 MUST be indicated in the "AAL type" field. 


Coding and procedure related to the ’Forward and Backward Maximum 
CPCS-SDU Size’ fields are discussed in [ATKI94]. Values may range 
from zero to 65,535. Although the default IP over AAL 5/ATM is 9188 
bytes, endstations are encouraged to support MTU sizes up to and 
including 64k. 


Ordinarily, no Service Specific Convergence Sublayer (SSCS) will be 
used for multiprotocol interconnect over AAL5. Therefore, the SSCS 


‘type’ field SHOULD be absent or, if present, coded to Null SSCS. 


Format and field values of AAL Parameters IE 


| aal_type 5 (AAL 5) | 
| fwd_max_sdu_size_identifier 140 
| fwd_max_sdu_size 65,535 (desired IP MTU) | 
| bkw_max_sdu_size_identifier 129 | 
| bkw_max_sdu_size 65,535 (desired IP MTU) | 
sscs_type identifier 132 
sscs_type 0 (null SSCS) 
6.2. Broadband Low Layer Information 


Selection of an encapsulation to support IP over an ATM VCC is done 
using the Broadband Low Layer Information (B-LLI) IE, along with the 
AAL Parameters IE, and the B-LLI negotiation procedure. 


RFC 1577 specifies LLC/SNAP as the default encapsulation. This 
encapsulation MUST be implemented by all endstations. LLC 
encapsulation MUST be signaled in the B-LLI as shown below. 

Signaling indication of other encapsulations is discussed in Appendix 
D, Section 4. Note that only LLC is indicated in the B-LLI. It is up 
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to the LLC layer to look into the encapsulation header of the packets 
following call setup. A B-LLI specifying both LLC and a layer_3_id 

SNAP layer is not recommended. If in those packets, the SNAP header 
indicates IP, it is the LLC layer’s job to hand the packets up to IP. 


Format of B-LLI IE indicating LLC/SNAP encapsulation 


| layer_2_id 2 
| user_information_layer 12 (lan_lle - ISO 8802/2) | 
6.2.1. Framework for Protocol Layering 


The support of connectionless services from a connection oriented 
link layer exposes general problems of connection management, 
specifically the problems of connection acceptance, assignment of 
quality of service, and connection shutdown. For a connection to be 
associated with the correct protocol on the called host, it is 
necessary for information about one or more layers of protocol 
identification to be associated with a connection "management entity" 
or "endpoint". This association is what we call a binding in this 
memo. In this section we attempt to describe a framework for a 
usable binding or service architecture given the available IEs in the 
ATM call control messages. 


It is important to distinguish between two basic uses of protocol 
identification elements present in the UNI setup message. The first 
is the description of the protocol encapsulation that will be used on 
the data packet over the virtual connection, the second is the entity 
that will be responsible for managing the call. All protocols present 
in various IEs MUST be used to encapsulate the call, but the most 
specific, or highest, layer specified SHOULD manage the call. This 
defines a hierarchy of services and provides a framework for 
applications, including LLC and IP, to terminate calls. This 
hierarchy provides a clear mechanism for support of higher level 
protocol and application bindings, when their use and specification 
is defined in the appropriate standards bodies. 


In general, it would be desirable to allow data packets to be stored 
directly into an application’s address space after connection is 
established. This is possible only if we have both encapsulation and 
managing entity indications in the signaling message. 
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The B-LLI is the only information element currently available in UNI 
3.1 for designating protocol endpoints. It contains codepoints that 
describe layer 2 and layer 3 protocol entities associated with the 
call. There are other information elements under consideration in the 
ATM Forum and ITU, which could come to play a significant role in the 
description of application to connection binding, but their use is 
not yet defined, and they are not part of the framework described by 
RFC 1577. They include B-HLI, for containing information for a higher 
layer protocol, Network Layer Information (NLI) to contain 
information for the network layer, and UUI, which is meant to carry 
information for use by the top level application. 


The following figure shows a B-LLI that MAY be used for specifying in 
call setup that IP will manage the call and that this VC will be used 
only for IP traffic. Called parties MUST accept this B-LLI. The 
caller using VC MUST use LLC-SNAP encapsulation on all IP datagrams, 
despite the fact that the caller views the VC as dedicated to IP. 

The reason for this requirement is that while we require receivers to 
accept this form of call setup, they may choose whether or not to 
multiplex the call through LLC, in other words to ignore the Layer 3 
information. This choice is dependent on the receiver’s 
implementation’s protocol architecture and is local to the receiver. 


Format of B-LLI IE indicating VC ownership by IP 
(NOTE: LLC/SNAP encapsulation is still used) 


| layer_2_id 2 | 
| user_information_layer 12 (lan_llc - ISO 8802/2) | 
| layer_3_id 3 | 
| ISO/IEC TR 9577 IPI 204 (0xCC) | 


Null-encapsulated VCs are described in RFC 1483. Such a VC would 
result in the most direct form of binding a VC to IP. However, the 
method of signaling for this type of VC has not yet been integrated 
into the IP over ATM context. For completeness, we mention that the 
signaling would use a B-LLI containing the layer 3 identifier with 
the ISO/IEC TR-9577 protocol codepoint and omitting the layer 2 
identifier [ATMF93]. Since no layer 2 is specified, frames produced 
by AAL processing would be given directly to IP. Processing of this 
B-LLI is not required at this time. 
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7. 


7. 


Information Elements with Significance to the ATM Network 


This section describes the coding of, and procedures surrounding, 
information elements with significance to the ATM network, as well as 
the endpoints of an ATM call supporting multiprotocol operation. 


The standards, implementation agreements, research and experience 
surrounding such issues as traffic management, quality of service and 
bearer service description are still evolving. Much of this material 
is cast to give the greatest possible latitude to ATM network 
implementation and service offerings. ATM endsystems need to match 
the traffic contract and bearer service they request from the network 
to the capabilities offered by the network. Therefore, this memo can 
only offer what, at the present time, are the most appropriate and 
efficient coding rules to follow for setting up IP and ATMARP VCCs. 
Future revisions of this memo may take advantage of ATM services and 
capabilities that are not yet available. 


1. ATM Traffic Descriptor 


The ATM traffic descriptor characterizes the ATM virtual connection 
in terms of peak cell rate (PCR), sustainable cell rate (SCR), and 
maximum burst size. This information is used to allocate resources 
(e.g., bandwidth, buffering) in the network. In general, the ATM 
traffic descriptor for supporting multiprotocol interconnection over 
ATM will be driven by factors such as the capacity of the network, 
conformance definition supported by the network, performance of the 
ATM endsystem and (for public networks) cost of services. 


The most convenient model of IP behavior corresponds to the Best 
Effort Capability (see section 3.6.2.4 of [ATMF93]). If this 
capability is offered by the ATM network(s), it MAY be requested by 
including the Best Effort Indicator, the peak cell rate forward 
(CLP=0+1) and peak cell rate backward (CLP=0+1) fields in the ATM 
Traffic Descriptor IE. When the Best Effort Capability is used, no 
guarantees are provided by the network, and in fact, throughput may 
be zero at any time. This type of behavior is also described by RFC 
1633 [BRAD94]. 


Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 11] 


RFC 1755 ATM Signaling Support for IP over ATM February 1995 


Format and field values of ATM Traffic Descriptor IE 


| fwd_peak_cell_rate_0+1_identifier 132 

| fwd_peak_cell_rate_0+1 (link rate) | 

| bkw_peak_cell_rate_0+1_identifier 133 | 
bkw_peak_cell_rate_0+1 (link rate) 
best_effort_indication 190 


When the network does not support Best Effort Capability or more 
predictable ATM service is desired for IP, more specific traffic 
parameters MAY be specified and the Best Effort capability not used. 
Doing so includes use of two other traffic-related IEs and is 
discussed in the following paragraphs and sections. 


The Traffic Descriptor IE is accompanied by the Broadband Bearer 
Capability IE and the QoS Parameter IE. Together these define the 
signaling view of ATM traffic management. In this memo, we present 
an agreed-on, required subset of traffic management capabilities, as 
specified by using the three IEs. The figure immediately below shows 
the set of the allowable combinations of traffic parameters which all 
IP over ATM endsystems MUST support in their ATM signaling. The 
subset includes Best Effort in the form of a non-guaranteed bitrate 
combination (the rightmost column of the table below); a type of 
traffic description that is intended for ATM "pipes", for example 
between two routers (the middle column); and a type of traffic 
description that will allow initial use of token-bucket style 
characterizations of the source, as presented in RFC 1363 [PART92] 
and RFC 1633, for example (the leftmost column). 
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Combinations of Traffic Related Paramenters 
that MUST be supported in the SETUP message 
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= Parameter is coded to either 
(Traffic Type/Timing Required) 


|Broadband Bearer | 
|Capability | 


| 

Traffic Type 

| (CBR, VBR) | 
| 
| 
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|Timing Required 

ee ee | 
|Traffic Descriptor | 
Parameter | 


|Best Effort 


| Tagging 
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is absent; 


treated as equivalent 
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or VBR or octet 5a 
these three codings are 


or octet 5a 


these three codings are treated as equivalent 


Use of other allowable combinations of traffic parameters listed in 


the large table in Appendix C may work, 
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and the called endsystem. 
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If Best Effort service is not use, link rate SHOULD not be requested 
as the peak cell rate. Without any knowledge of the application, it 
is RECOMMENDED that a fraction, such as 1/10th, of the the link 
bandwidth be requested. 


[ATMF93] does not provide any capability for negotiation of the ATM 
traffic descriptor paramenters. This means that: 


a) the calling endsystem SHOULD have some prior knowledge as to 
the traffic contract that will be acceptable to both the 
called endsystem and the network. 


b) if, in response to a SETUP message, a calling endsystem 
receive a RELEASE COMPLETE message, or a CALL PROCEEDING 
message followed by a RELEASE COMPLETE message, with cause 
#37, User Cell Rate Unavailable, it MAY examine the 
diagnostic field of the Cause IE and reattempt the call after 
selecting smaller values for the parameter(s) indicated. If 
the RELEASE COMPLETE or RELEASE message is received with cause 
#73, Unsupported combination of traffic parameter, it MAY 
try other combinations from table 5-7 and 5-8 of [ATMF93]. 


c) the called endsystem SHOULD examine the ATM traffic descriptor 
IE in the SETUP message. If it is unable to process cells at 
the Forward PCR indicated, it SHOULD clear the call with cause 
#37, User Cell Rate Unavailable. 
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7.2. Broadband Bearer Capability 


Broadband Bearer Connection Oriented Service Type X (BCOB-X) or Type 
C (BCOB-C) are both applicable for multiprotocol interconnection, 
depending on the service(s) provided by the ATM network and the 
capabilities (e.g., for traffic shaping) of the ATM endsystem. The 
table in the previous section showed the use of BCOB-X and BCOB-C 


with other parameters. The figure below shows format and field 
values for a BCOB-X when the Traffic Descriptor IE indicates Best 
Effort. 


Format and field values of Broadband Bearer Capability IE 


| spare 0 | 
| bearer_class 16 (BCOC-X) 
| spare 0 | 
| traffic_type 0 (no indication) | 
| timing_reqs 0 (no indication) | 
susceptibility_to_clipping 0 (not suscept) 
spare 0 
| user_plane_configuration 0 (point_to_point) | 


IP over ATM signaling MUST permit BCOB-C and BCOB-X, in the 
combinations shown in the previous section. It MAY also permit one 
of the allowable combinations shown in Appendix C. 


Currently, there is no capability for negotiation of the broadband 
bearer capability. This means that: 


a) the calling endsystem SHOULD have some prior knowledge as to 
the broadband bearer capability that will be acceptable to 
both the called endsystem and the network. 


b) if, in response to a SETUP message, a calling endsystem 
receives a RELEASE COMPLETE message, or a CALL PROCEEDING 
message followed by a RELEASE COMPLETE message, with cause 
#57, bearer capability not authorized or #58 bearer capability 
not presently available, it MAY reattempt the call after 
selecting another bearer capability. 
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7.3. QoS Parameter 


The Unspecified QoS class (Class 0) is the only QoS class that must 
be supported by all networks and the only QoS class allowed when 
using the Best Effort service. The Specified QoS Class for Connection 
Oriented Data Transfer (Class 3) or the Specified QoS Class for 
Connectionless Data Transfer (Class 4) may be applicable to 
multiprotocol over ATM, but their use has to be negotiated with the 
network provider. The combinations of QoS parameters with the ATM 
Traffic Descriptor and the Broadband Bearer Capability are detailed 
in the Traffic Descriptor section and in Appendix C. 


Format and field values of QoS Parameters IE 


| qos_class_fwd 0 (class 0) 
| qos_class_bkw 0 (class 0) 


[ATMF93] does not provide any capability for negotiation of Quality 
of Service parameters. This means that: 


a) the calling endsystem SHOULD have some prior knowledge as to 
the QoS classes offered by the ATM network in conjunction with 
the requested Broadband Bearer Service and Traffic Descriptor. 


b) if, in response to a SETUP message, a calling endsystem 
receives a RELEASE COMPLETE message, or a CALL PROCEEDING 
message followed by a RELEASE COMPLETE message, with cause 
#49, Quality of Service Unavailable, it MAY reattempt the call 
after selecting another QoS class. 


Note: The two-bit ’coding standard’ field of the General Information 
octet in the IE header, SHOULD be set to ’00’ now that the ITU-T has 
standardized QoS class 0. Endsystems SHOULD treat either value (’11’ 
or ’00’) as requesting the ITU-T QoS class. 


7.4. ATM Addressing Information 


ATM addressing information is carried in the Called Party Number, 
Calling Party Number, and, under certain circumstance, Called Party 
Subaddress, and Calling Party Subaddress IE. Section 5.8 of [ATMF93] 
provides the procedure for an ATM endsystem to learn its own ATM 
address from the ATM network, for use in populating the Calling Party 
Number IE. Section 5.4.5.14 [ATMF94] describes the syntax and 
semantics of the calling party subaddress IE. 
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RFC 1577 RECOMMENDS that a router be able to provide multiple LIS 
support with a single physical ATM interface that may have one or 
more individual ATM endsystem addresses. Use of the Selector field 
in the NSAPAs and E.164 addresses (in the NSAP format) is identified 
as a way to differentiate up to 256 different LISs for the same ESI. 
Therefore, an IP router MAY associate the IP addresses of the various 
LISs it supports with distinct ATM addresses differentiated only by 
the SEL field. If an IP router does this association, then its 
signaling entity MUST carry in the SETUP message the ATM addresses 
corresponding to the particular IP entity requesting the call, and 
the IP entity it is requesting a call to. These ATM addresses are 
carried in the Calling and Called Party Number IEs respectively. 
Native E.164 addresses do not support a SEL field. For IP routers 
residing in a Public UNI where native E.164 addresses are used it is 
RECOMMENDED that multiple E.164 addresses be used to support multiple 
LISs. Note: multiple LIS support is the only recommended use of the 
SEL field. Use of this field is not recommended for selection of 
higher level applications. 


Resolution of IP addresses to ATM addresses is required of hosts and 
routers which are ATM endsystems that use ATM SVCs. RFC 1577 provides 
a mechanism for doing IP to ATM address resolution in the classical 
IP model. 


Format and field values of Called and Calling Party Number IE 


| type_of_number (international number / unknown) | 
| addr_plan_ident (ISDN / ATM Endsystem Address) | 
| addr_number (E.164 / ATM Endsystem Address) 


international number / unknown) | 
ISDN / ATM Endsystem Address) 
presentation allowed) 


| type_of_number 
addr_plan_ident 
presentation_indic 
| spare | 
| screening_indic user provided verified & passed) | 
| addr_number E.164 / ATM Endsystem Address 


mam a OAR AAR 
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8. Dealing with Failure of Call Establishment 


If an ATM call attempt fails with any of the following causes, the 
situation SHOULD be treated as Network Unreachable (if the called ATM 
endsystem is a router) or Host Unreachable (if the called ATM 
endsystem is a host). See the treatment of Network and Host 
Unreachable conditions in RFC 1122 [BRAD89]. 


1 unallocated (unassigned) number 
3 no route to destination 
17 user busy 
18 no user reponding 
27 destination out of order 
38 network out of order 
41 temporary failure 
47 resource unavailable, unspecified 


Se 4E SR SER SE SR SE te 


If an ATM call attempt fails with any of the following causes, the 
ATM endsystem MAY retry the call, changing (or adding) the IE(s) 
indicated by the cause code and diagnostic. 


# 2 no route to specified transit network 
# 21 call rejected 
# 22 number changed 
# 23 user rejects call with CLIR 
# 37 user cell rate unavailable 
# 49 quality of service unavailable 
# 57 bearer capability not authorized 
# 58 bearer capability not presently available 
# 65 bearer capability not implemented 
# 73 unsupported combination of traffic parameter 
# 88 incompatible destination 
# 91 invalid transmit network selection 
# 78 AAL parameter cannot be supported 
9. Security Considerations 


Not all of the security issues relating to IP over ATM are clearly 
understood at this time, due to the fluid state of ATM 
specifications, newness of the technology, and other factors. Future 
revisions of this specification will address the security 
capabilities that future signaling standards may offer to IP over ATM 
signaling. 
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10. Open Issues 
(0) This document version is specifically an RFC 1577/RFC 1483 
implementation document. Although RFC 1577 and RFC 1483 
specify an LLC/SNAP encapsulation, which is inherently a 
multiprotocol encapsulation, it is beyond to scope of this 
document to go into any multiprotocol specifications other than 
to point out some examples (see Appendix D for an example of 
NLPID encapsulation). 
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Appendix A. Sample Signaling Messages 
1. SETUP and CONNECT messages 


This appendix shows sample codings of the SETUP and CONNECT signaling 
messages. The fields in the IE header are not shown. 


Information Elements/ 
Fields Value/ (Meaning) 


aal_parameters 


aal_type 5 (AAL 5) 
fwd_max_sdu_size_ident 140 
fwd_max_sdu_size (send IP MTU value) 
bkw_max_sdu_size_ident 129 
bkw_max_sdu_size (recv IP MTU value) 
sscs_type identifier 132 

sscs_type 0 (null SSCS) 


user_cell_rate 


fwd_peak_cell_rate_0_1_ident 132 
fwd_peak_cell_rate_0_1 (link rate) 
bkw_peak_cell_rate_0_1_ident 133 
bkw_peak_cell_rate_0_1 (link rate) 


best_effort_indication 190 


bb_bearer_capability 


spare 0 

bearer_class 16 (BCOC-X) 

spare 0 

traffic_type 0 (no indication) 

timing_reqs 0 (no indication) 

susceptibility_to_clipping 0 (not susceptible to 

clipping) 

spare 0 

user_plane_configuration 0 (point_to_point) 
bb_low_layer_information 

layer_2_id 2 

user_information_layer 12 (lan_lle (ISO 8802/2) 
gqos_parameter 

gqos_class_fwd 0 (class 0) 

gqos_class_bkw 0 (class 0) 
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called_party_number 


type_of_number (international number / unknown) 
addr_plan_ident (ISDN / ATM Endsystem Address) 
number (E.164 / ATM Endsystem Address) 


calling_party_number 
type_of_number 
addr_plan_ident 
presentation_indic 


international number / unknown) 
ISDN / ATM Endsystem Address) 
presentation allowed) 


maa OR AR 


spare 
screening_indic user_provided verified and passed) 
number E.164 / ATM Endsystem Address) 
4+--------------------------- - - - - - 5 ee + 
Figure 1. 
Sample contents of SETUP message 
[* : optional, ignored if present] 
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In IP over ATM environments the 
is *mandatory* to allow for MTU 
and destination. The "Broadband 
mandatory for specifying the IP 


inclusion of the "AAL parameters" IE 
size negotiation between the source 
Low Layer Information" IE is also 
encapsulation scheme. 


4+---------------------------- - - - - 5 5 5 ee + 
CONNECT 
Information Elements/ 
Fields Value 
aal_parameters 
aal_type 5 (AAL 5) 
fwd_max_sdu_size_ident 140 
fwd_max_sdu_size (send IP MTU value) 
bkw_max_sdu_size_ident 129 
bkw_max_sdu_size (recv IP MTU value) 
sscs_type identifier 132 
sscs_type 0 (null SSCS) 
bb_low_layer_information 
layer_2_id 2 
user_information_layer 12 (lan_lle (ISO 8802/2) 
connection identifier 
spare 0 
vp_assoc_signaling 1 (explicit indication of VPCI) 
preferred_exclusive 0 (exclusive vpci/vci) 
vpci (assigned by network) 
vei (assigned by network) 
4+--------------------------- - - - - eee + 


Figure 2. 
Sample contents of CONNECT message 


As in the SETUP message, IP over ATM environments demand the 
inclusion of the "AAL parameters" IE so that the destination may 
specify the MTU size that it is willing to receive. 


2. Hints on Use of CALL PROCEEDING Message 


Use of the CALL PROCEEDING message is beneficial in implementations 
where the called party’s ATM signaling entity and AAL Users are 
decoupled. An arriving SETUP may result in an immediate CALL 
PROCEEDING response from the called party’s ATM signaling entity, 
while it locally queries the called IP-ATM entity to see if the 
SETUP’s conditions are acceptable. The acceptance of the SETUP’s 
conditions would then cause the ATM signaling entity to issue a 


CONNECT back to the switch. The 


two possible refusal modes at the 
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called party then become: 


a) Called party has no IP-ATM entity resident. Issue RELEASE 
COMPLETE in response to SETUP. 


b) Called party has a resident IP-ATM entity, so CALL PROCEEDING 
was issued. The IP-ATM entity rejects the call request, soa 
RELEASE is issued instead (to be acknowledged by the network 
with RELEASE COMPLETE) . 


Appendix B. IP over ATM using UNI 3.0 Signaling 
This appendix describes how to support IP over ATM using UNI 3.0 


Signalling. Differences in the coding or semantics of each relevant 
IE is given. 


1. AAL parameter 
Values for maximum SDU size may range from one (not zero) to 64K. 


A ‘mode’ field is an allowable field in UNI 3.0. Nevertheless, this 
‘mode’ field SHOULD be omitted from the AAL Parameters IE and MUST be 
ignored by the destination endsystem. 


2. Traffic Management Related IEs 


In UNI 3.0 issues of traffic management were less understood than in 
UNI 3.1. UNI 3.0 does not contain a guide to coordinating the use of 
the User Cell Rate IE (Traffic Descriptor IE in UNI 3.1), Broadband 
Bearer Capability IE, and QoS parameters IE. Therefore, the 
recommendation for specifying parameters in these IEs is the same as 
that given above when using UNI 3.1. The following section merely 
describes relevant differences in names and code values. 


2.1 ATM User Cell Rate (instead of ATM Traffic Descriptor) 
The ATM Traffic Descriptor IE is refered to as ’ATM User Cell Rate’ 


IE in UNI 3.0. Also, the value for the cause ’user cell rate 
unavailable’ is #51. 


2.3 QoS parameters 


The two-bit ’coding standard’ field of the General Information octet 
in the IE header, should be set to ’11’ inidicating that the IE is a 
standard defined for the network (as opposed to an ITU-TS standard) 
present on the network side of the interface. 
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3. ATM Addressing Information 

In UNI 3.1, the ’ATM Endsystem Address’ type was introduced to 
differentiate ATM addresses from OSI NSAPs. In UNI 3.0, ’ATM 
Endsystem Address’ is not a valid type. Therefore, in the called and 
calling party subaddress IEs the three-bit ‘’type of subaddress’ field 
MUST specify ’NSAP’ (value = 001) when using the subaddress IE to 
carry ATM addresses. 


4. Dealing with Failure of Call Establishment 


In UNI 3.0 the there are certain cause values which are different 
than UNI 3.1. Two relevant differences are the following: 


‘AAL Parameter Cannot Be Supported’ is #93 (#78 in UNI 3.1), and 


‘User Cell Rate Unavailable’ is #51 (#37 in UNI 3.1). 
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Appendix C. 


Combinations of Traffic Related Parameters 
tha MAY be supported in the SETUP message 


|Broadband Bearer | 
|Capability | 


Broadband Bearer 


[Arc] x |x je | x [cl] x | |c] 
|--------------------- |---]---]--- |---|---]-|---]---|--- |---|-|--- 

Traffic Type | | | 

-i y 

| [| ¥ fee | fse | jse] | | 


(CBR, VBR) 


Traffic Descriptor 
|Parameter | 


|Best Effort 


Tagging 


(Table 2 is a reproduction of Table F-1 of Appendix F in [ATMF 94].) 


Peak Cell Rate, SCR = Sustainable Cell Rate, 
Maximum Burst Size 


Y = Yes, N = No, S = Specified 


Y/N = either "Yes" or "No" is allowed 
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* = allowed QoS class values are a network option. Class 0 is 
always supported for alignment with ITU-T 


& = parameter is coded to either "no indication" or VBR or 
octet 5a(Traffic Type/Timing Required) is absent; these three 
codings are treated as equivalent 


&& = parameter is coded to either "no indication" or "No" or 
octet 5a(Traffic Type/Timing Required) is absent; these three 
codings are treated as equivalent 


A blank entry in the table indicates that the parameter is not 
present. 


Appendix D. Frame Relay Interworking 


t: 


RFC 1490 over FR-SSCS vs. RFC 1483 over null-sscs 


Procedures for Frame Relay to ATM signaling interworking have not yet 
been specified by ITU-T, the ATM Forum, or the Frame Relay Forum. If 
an ATM endsystem wishes to use FR-SSCS, FR-SSCS and RFC 1490 
encapsulation must both be be specified in the SETUP message. 
Nevertheless, since neither LLC encapsulation nor VC-multiplexing 
will interoperate when used over FR-SSCS, these two encapsulations 
cannot be negotiated as alternatives to RFC 1490 encapsulation (see 
Section 4, Encapsulation Negotiation). 


In ATM environments the SSCS layer is part of the AAL functionality. 
The SSCS serves to coordinate the needs of a protocol above with the 
requirements of next lower layer, the Common Part Convergence 
Sublayer (CPCS). For example, the UNI ATM signaling protocol runs on 
top of a signaling SSCS which among other things provides an assured 
transfer service for signaling messages. Since the SSCS is considered 
part of the AAL, the SSCS type is specified as one of the parameters 
in the AAL Parameters IE. To date there has not been an SSCS defined 
for data transmission in ATM and this type field is usually set to 
‘null’; 


The exception occurs when doing FR interworking where an ATM 
endsystem may choose to use the FR-SSCS over AAL 5 in order to 
communicate with a FR endsystem. In that case the SSCS type in the 
AAL Parameters IE of the SETUP message is set to ’FR-SSCS’. 


Also included in a SETUP message is an indication in the B-LLI IE of 
the protocol layers to be used above the AAL. In particular, ATM 
connections established to carry connectionless network interconnect 
traffic require a layer above the AAL for multiplexing multiple 
protocols over a single VC [HEIN 93]. As mentioned above, RFC 1577 
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defines LLC as default multiplexing layer for IP over AAL5. 


Specification of the SSCS restricts the encapsulation protocol used 
over it, since RFC 1483 (in addition to applicable ITU standards) 
defines the use of RFC 1490 encapsulation over the FR-SSCS, and LLC 
or null encapsulation otherwise. The fact that it is not possible, 
in the UNI 3.0 signaling specification, to negotiate between the FR- 
SSCS and null-SSCS can result in interoperability restrictions 
between stations that implement and wish to use the FR-SSCS and those 
that do not, even though they both are using IP. The guidelines in 
the following section were developed to decrease the chance that such 
interoperability restrictions occur. 


2. Scenarios for Interworking 


The following discussion uses the terms "network interworking" and 
"service interworking". "Network interworking" uses FR-SSCS over 
AAL5 between the InterWorking Unit (IWU) and the ATM endsystem, and 
the ATM endsystem is aware that the other endpoint is a FR/ATM 
Network IWU. "Service interworking" aims to make the operation 
transparent to the ATM endsystem by adding encapsulation translation 
and other payload processing in the FR/ATM Service IWU to allow the 
ATM endsystem to operate as if it were talking to another ATM 
endsystem. 


The most common scenario where FR-SSCS could be negotiated is between 
an ATM endsystem and a FR/ATM network IWU to allow connectivity among 
an ATM endsystem and a FR endsystem residing behind a FR/ATM network 

IWU. 


[ny me | FR/ATM | | A™ | | B | 
| (FR) |----- >| Iwu | ----- >| switch | ----- >| (ATM) | 
| | 
----- > —--------------------> 
FR call ATM call 


A network IWU can place a call to an ATM host (on behalf of a FR 
host) by signaling for FR-SSCS and assuming that the ATM endsystem 
supports FR-SSCS. The B-LLI IE SHALL be encoded to indicate RFC 1490 
encapsulation and the SSCS type field of the AAL Parameters IE SHALL 
be coded to indicate FR-SSCS. If the FR-SSCS negotiation fails 
because the called ATM host does not support FR-SSCS, the IWU can 
retry the call negotiating for LLC encapsulation or VC-multiplexing. 
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the retry if it is able to do FR- 


Such service interworking adds extra 


processing overhead during the call. 


The even more problematic case occurs when a call is requested in the 


opposite direction, i.e. 
residing behind an IWU. 


| B | | FR/ATM | 
| (FR) |<----- | Iwọ |<----- 
B | | 
| | 
< a Na ae 
FR call 


when an ATM host places a call to a host 


| 
| AM | beets tl 
| switch |<----- | (ATM) | 
| J ene 
< Ss Nh aa a el led ab me ele al dh 
ATM call 


Not knowing that the destination resides behind an IWU, the calling 


host will negotiate for the default LLC encapsulation 
requesting VC-multiplexing as an alternative). 


(possibly 
In this situation the 


IWU can accept the call and do the necessary service interworking or 


reject the call specifying ’AAL Parameters not supported’. 


If the IWU 


rejects the call it risks the possibility that calling host does not 
support FR-SSCS or simply does not retry and the call will never be 


established. 
Possible Alternatives 


While Frame Relay interworking is 


negotiate FR-SSCS with LLC encapsulation or VC-multiplexing, 
decreases the chances of completing an ATM call. 


interoperability can be increased 


1. Maintaining external knowledge 
FR-SSCS. 
some network host database. 


2. 


cases: 


2a. 
and prefers service interworking. 
using LLC encapsulation. 


Perez, Liaw, Mankin, Hoffman, 


This knowledge can be configured, 


In the absence of such external knowledge, 
required to negotiate for the default LLC encapsulation 
requesting VC-multiplexing as an alternative). 


Grossman & Malis 


possible, it is not possible to 
which 
However, 


using the following alternatives: 


that a particular destination uses 
or in the future added to 


an ATM endsystem is 
(possibly 
There are three sub- 


The IWU supports service interworking and network interworking, 


The IWU simply accepts the call 
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2b. The IWU supports service interworking and network interworking, 
and prefers network interworking. The IWU simply accepts the call, 
but attempts to open a parallel connection back to the original ATM 
endsystem negotiating the FR-SSCS use. If the connection is 
accepted, the IWU closes the service interworking connection. 


2c. The IWU supports network interworking only. The IWU rejects the 
call specifying ’AAL Parameters not supported’, and then attempts to 
open a connection back to the original ATM endsystem negotiating the 
FR-SSCS use. 


4. Encapsulation negotiation 


The call/connection control signaling protocol includes a mechanism 

to support negotiation of encapsulation for endsystems that support 

more than one. This section describes the procedures for negotiation 
of an encapsulation. 


The B-LLI negotiation procedures (see Annex C of [ATMF93]) are 
initiated by the calling ATM endsystem by including up to three 
instances of the B-LLI IE in the SETUP message in descending order of 
preference (following the rule for repeating IE in section 5.4.5.1 of 
[ATMF93]). 


The following is the list of the three possible combinations that B- 
LLI IE instances MAY be included in the SETUP message. Each instance 
is referred to by its encapsulation name as it appears in RFC 1483, 
and corresponding section labels from Appendix D of the ATM Forum UNI 
3.0 specification. 


a) LLC/SNAP encapsulation (D.3.1) 


In this case, the calling ATM endsystem can only send and receive 
packets preceded by an LLC/SNAP identification. This memo requires 
that hosts and routers which are ATM endsystems implement LLC/SNAP 
encapsulation. 


b) VC-multiplexing (D.3.2) and LLC/SNAP (D.3.1) 
The calling ATM endsystem prefers to use VC multiplexing, but is 
willing to agree to use LLC/SNAP encapsulation instead, if the called 
ATM endsytem only supports LLC/SNAP. 

c) RFC 1490 encapsulation (NLPID multiplexing) over FRSSCS 


(D.3.3, omitting octets 7a and 7b and MUST have FR-SSCS in SSCS 
type of AAL Parameters IE.) 


Perez, Liaw, Mankin, Hoffman, Grossman & Malis [Page 31] 


RFC 1755 ATM Signaling Support for IP over ATM February 1995 


The calling ATM endsystem can only send and receive packets using RFC 
1490 encapsulation (NLPID multiplexing) over FRSSCS. Use of RFC 1490 
encapsulation presently cannot be negotiated as an alternative to LLC 
encapsulation or VC-multiplexing. If the B-LLI IE is encoded to 
indicate RFC 1490 encapsulation, the SSCS type field of the AAL 
Parameters IE SHALL coded to indicate FRSSCS. Note that the AAL 
Parameters IE can not be coded to indicate both NULL and FR-SSCS and 
neither LLC encapsulation nor VC-multiplexing will be interoperable 
when used over FR-SSCS. 


The called ATM endsystem SHALL select the encapsulation method it is 
able to support from the B-LLI IE present in SETUP message. If it 
supports more than one of the encapsulations indicated in the SETUP 
message, it MUST select the one which appears first in the SETUP 
message. The called ATM endsystem then includes the B-LLI IE content 
corresponding to the selected encapsulation in the CONNECT message. 
If the called endsystem does not support any encapsulation indicated 
in the incoming SETUP message, it SHALL clear the call with cause 
#88, incompatible destination. If the received SETUP message does 
not include the B-LLI IE, the call SHALL be cleared with cause #21, 
"call rejected", with diagnostics indicating rejection reason = 
information element missing and the B-LLI IE identifier. As 
described in Annex C of [ATMF93], if the calling ATM endpoint 
receives a CONNECT message that does not contain a B-LLI IE, it SHALL 
assume the encapsulation indicated in the first BLLI IE that it 
included in the SETUP message. 
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